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(54) l\/lethod of transferring connection management information in world wide web requests and 
responses 



(57) In order to reduce the delay and/or loss of pack- 
ets caused by the transmission through a large number 
of routers on the Internet, a direct connection is estab- 
lished between a client (or its proxy) and a server i1 the 
client (or its proxy) and the server are connected to the 
same alternative subnetwork. Control management in- 
formation, including the type of subnetwork to which 



each is connected, as well as the address of the client 
(or its proxy) and the server are transmitted to the other 
on the Internet in an optional HTTP header field. After 
receipt of the addressing information, a direct connec- 
tion is established on the alternative subnetwork be- 
tween the client (or its proxy) and the server for purpos- 
es of streaming information from the server to the client. 
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Description 

Technical Field 

This invention relates to data communications and 
computer networking. 

Background of the Invention 

As the Internet becomes more complex, comprising 
a continuously increasing number of interconnected 
networks, the packetlzed requests from client terminals 
and packetized server responses pass through an ever 
increasing number of routers between the two end- 
points. It is not uncommon, tor example, that these pack- 
ets traverse eighteen or more routers along their route. 
Since the Internet does not provide any guaranteed 
Quality of Service (QoS), certain packets may be de- 
layed or lost as they pass through these routers, which 
likelihood increases with the number of routers through 
which the packets traverse. If a stream of packets trans- 
mitted from a server to a client contains real-time multi- 
media content (audio, video, and data), the received 
stream may contain Missing or delayed packets. In 
many cases, such missing packets may necessitate that 
the client re-request the content of the previously re- 
quested URL, thereby requiring the server to resend the 
entire content. For a transmitted video clip, for example, 
this is analogous to rewinding a video tape to its begin- 
ning and re-watching the entire tape to view the missing 
portion. This is a waste of resources of the server, the 
network, and the time of the user at the client. 

In some environments where the clients and the 
servers are on the same subnetwork, such as the same 
ATM network or ISDN network (a public switched or pri- 
vate ISDN network, for example), the downstreaming of 
information from the server to the client can bypass the 
routers, and thus the delay and toss-imparting network 
elements, if the stations at both endpoints are provided 
with each other's address on their common subnetwork. 
For example, if the client and server know of each oth- 
er's address in the ISDN domain, a direct connection 
can be established on the ISDN network, as opposed to 
the Intemet, for at least the streaming of information 
from the server to the client. The key element in being 
able to use subnetwork inlerconnectivity is thus provid- 
ing one endpoint with the subnetwork address of the oth- 
er from which a direct connection between the endpoints 
can be established on the subnetwork. 

A fairly general way to discover such subnetwork 
addresses is to place special address translating serv- 
ers in the Internet network. Clients and servers can then 
query these address translators to obtain the subnet- 
work addresses. In order to allow provide wide area in- 
terconnectivity between clients and servers, a signifi- 
cant infrastructure is necessary to put such a network 
of translators in place. Furthermore, in order to enable 
clients and servers to take advantage of these translator 



servers within the Internet, the software on both the cli- 
ents and host servers end devices must be modified to 
access the translator servers to obtain the alternate ad- 
dress Information. 

5 

Summary of the Invention 

In accordance with the present invention, connec- 
tion management information is transferred between 
10 Web clients and servers by means of messages incor- 
porated in optional header fields of the HTTP protocol 
header: the HTTP protocol being protocol through which 
web clients and servers communicate with each other. 
These fields In an HTTP message carry Information re- 
lated to connect ton management that is used tor direct 
communication of the client and server along alternative 
paths that provide a QoS greater than what can be 
achieved over the Internet. 

The connection management Information, incorpo- 
rated within optional header fields of the HTTP protocol 
header, includes addressing information which specifies 
addresses on a subnetwork, such as ATM addresses, 
ISDN or POTS E.164 numbers, as well as an alternate 
Internet Protocol (IP) address that may be used to com- 
municate over non-persistent or switched paths. In ad- 
dition, the addressing infomr^tion includes the subnet- 
work type on which the addresses are applicable. Ex- 
amples of the latter may Include the IEEE 802 family of 
networks (e.g.. Ethernet or token-ring), Emulated LAN 
(ELAN), ATM, ISDN, FR (Frame Relay), and X.25 virtual 
circuit networks. Further, for those subnetworks for 
which QoS can be controlled, such as ATM or FR net- 
works, the connection management information trans- 
mitted In the header fields can also include QoS infor- 
mation such as a required bandwidth, maximum packet 
delay, maximum variance of packet delay, maximum 
packet loss, and preferred Socket type (e.g., datagram 
(UDP), or stream (TCP)). 

The optional headers In the HTTP message con- 
taining the connection management information may be 
inserted by a server, a client, or an intermediate system 
on behalf of the client, the latter referred to as a proxy 
on the World Wide Web (WWW). The HTTP messages 
are initially delivered over a router network (e.g., the In- 
ternet), using multiple router hops rather than a direct 
connection between the communication endpoints. The 
Web client or server endpoint then uses the additional 
addressing information contained in the header to es- 
tablish a direct connection to the other endpoint to pro- 
vide services (e.g., the delivery of information) on the 
direct network connection. As an alternative, the ad- 
dress information provided to the other end can be of 
an Intermediate system (IS), such as the proxy or a spe- 
cialized router node, and rather than a direct connection 
between the two endpoints, one of the original endpoints 
may establish a direct connection on the subnetwork 
with the intermediate system. When the underlying sub- 
network Is capable of acting upon OoS information. QoS 
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information included in the header may be used by ei- 
ther a client, or a proxy acting on behalf of the client. A 
program running on the client or proxy interprets the 
QoS response information, and indicates with what QoS 
a direct connection (known as a cut-through) between 5 
client and server is to be undertaken. 

Brief Description of the Drawings 

FIG. 1 shows the flow of information between a cli- 
ent and a server in establishing an initial connection 
over the Internet between the endpoints and a sub- 
sequent direct connection there between in re- 
sponse to the receipt in an HTTP request of a sub- 
network type and an address; 
FIG. 2 shows the flow of information between a cli- 
ent, a proxy and a server, wherein the server sets 
up a direct connection to the proxy; 
FIG. 3 shows the flow of information between a cli- 
ent, a proxy and a server wherein the server sets 
up a direct connection to the client; 
FIG. 4 shows the flow of information wherein the 
client initiates the cut-through to the server; and 
FIG. 5 shows the use of the present invention in a 
multimedia conferencing scenario. 

Detailed Description 

With reference to FIG. 1 , a first host, client terminal 
101, connected to a LAN 1 02, initiates an HTTP request 
through the Internet 103 to a second host, server 104, 
connected on LAN 105. This request is forwarded to 
server 104 through a series of hops 115-121 through 
routers (1 06 and 1 07) "off" the Internet and routers (1 08, 
109, 110 and 111) "on" the Internet. In accordance with 
the present invention, the HTTP request includes fields 
that provide connection management information. Spe- 
cifically, the HTTP header fields include the type of sub- 
network to which client 1 01 is also connected to, as well 
as the subnetwork address of client 101. Such subnet- 
work addressing information can be used to establish a 
direct connection between the client and server hosts, 
when both such hosts are attached to the same "logical" 
subnetwork type (e.g., both hosts have ISDN interfaces, 
or both are members of a corhmon ATM inter-network). 

When server 104 receives the HTTP request, it di- 
rectly sets up a connection (1 22) on a subnetwork. Once 
this cut-through is established, data flow proceeds on 
the subnetwork directly from server 104 to client 101, 
without needing to rely on the fonA^arding of packets by 
the IP routers. Depending on the capabilities of the end- 
points, the cut-through between server 104 and client 
101 may consist of an IP protocol-based communication 
(encapsulated within the subnetwork protocol), or a na- 
tive mode communication using only the subnetwork 
protocol mechanism. The latter approach may be em- 
ployed with emerging application interfaces such as 
WINSOCK II, which are capable of supporting multiple 



networking technologies underneath an abstract Appli- 
cation Programming Interface (API). The former ap- 
proach is employed when only legacy APIs such as 
WINSOCK I are available. 

As previously noted, when the underlying subnet- 
work is capable of acting upon QoS information, QoS 
information included with the HTTP header may be used 
by either a client, or a proxy host acting on behalf of the 
client. A program running on the client or proxy then in- 
terprets the QoS response information, and indicates 
with what QoS a cut-through between client and server 
should be undertaken. 

The scenarios described hereinbelow illustrate how 
the present invention can be utilized for WWW-based 
multimedia-on-demand applications, where a client 
downloads a file containing audio and/or video informa- 
tion for playback from a WWW server. 

It is assumed in these scenarios that the client uti- 
lizes a standard IP API. The communication path in each 
scenario is asymmetric. Communication from the client 
to the server follows the standard IP routed path. Com- 
munication from the server to the client/proxy follows the 
shortcut path. With the exception of the client-side proxy 
case below, no changes are needed on the client side. 

With reference to FIG. 2, a client 201 forwards an 
HTTP request 202 to proxy 203 via router 204 on the 
Internet 220, noted as steps SI and S2. Proxy 203 adds 
the subnetwork type and subnetwork address (SA) of 
an intermediate system (IS) as an optional header, and 
forwards a modified HTTP request 205 to HTTP server 
206. This request passes through routers 204, 207 and 
208, In steps S3, S4 and S5, to reach server 206. As 
noted in request 205, the subnetwork type indicated is 
ISDN, with an illustrative SA of 9089491234. This sce- 
nario depicts the special case where the IS address is 
that of the proxy itself. When server 206 receives the 
modified proxy request 205, it sets up a direct connec- 
tion to proxy 203, on the ISDN subnetwork 209, which 
passes through ISDN switches 210 and 211 (step S6). 
In step S7, server 206 responds to the proxy request 
205 with response 212 containing both control informa- 
tion and the requested media object. This response, re- 
ceived by proxy 203, is forwarded to client 201 via router 
204 in steps S8 and S9. 

In the scenario of FIG. 3, a direct connection is es- 
tablished between a HTTP server 302 and client 301 , 
rather than through the proxy 303 through which the cli- 
ent forwards its HTTP requests and receives is usual 
Internet responses. In FIG. 3, the client 301 forwards 
the HTTP request (not shown, but the same as request 
202 in FIG. 2) to proxy 303 via router 304 in Internet 320 
(steps SI and S2). Proxy 303 adds the subnetwork type 
to which it is connected (ISDN in this scenario) and the 
SA of client 301 as an optional header, and forwards the 
modified request to HTTP server 302 through routers 
305 and 306 on the Internet (steps S3, S4, and S5). 
Server 302 responds to the proxy request with an ac- 
knowledgment to proxy 303, back through routers 305 
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and 306, that the request succeeded (or not) and Infor- 
mation regarding the type of helper application needed 
by client 301 (step S6). In step S7. proxy 303 forwards 
that information back to client 301 through router 304. 
In response to that information, client 301 launches a 
helper application to handle the lype of content that ar- 
rived from the server (step S8). In step S9, server 302 
sets up a cut-through connection to client 301 on the 
ISDN subnetwork 310 to which client 301 and server 
302 are connected, through ISDN switches 307, 308 
and 309. The client 301 thereupon indicates to server 
302 through the ISDN subnetwork 310, that it is ready 
to receive information (step S10). Information is then be 
streamed from server 302 to client 301 on the cut- 
through ISDN connection. 

In the scenarios described hereinabove, the server 
initiates the cut-through to the client. In the scenario il- 
lustrated In FIG. 4, the client/proxy initiates the cut- 
through to the server. II is assumed that the client 401 
and the proxy 403 are co-resident on the same machine. 
It is also assumed that both client 401 and server 402 
utilize a WINSOCK II style API, where the API allows 
the selection of different networks for the transfer of da- 
ta. This allows client 401 to communicate directly with 
server 402 using the transport protocol stack corre- 
sponding to the chosen subnetwork address (SA) using 
two-way communication. This scenario could also be 
carried out using a conventional IP API such as WIN- 
SOCK 1 For this latter case, an extra step is needed, 
namely, client 401 needs to add a specific routing table 
entry, namely a route to the server over the direct con- 
nection. 

In FIG. 4, client 401 forwards an HTTP request to 
proxy 403 via an inter-process communication (step 
SI). Proxy 402 then adds the subnetwork type (ST) of 
client 401 (ISDN in this scenario) and forwards the mod- 
ified request to HTTP server 402 on the Internet 420 via 
routers 404, 405 and 406 (steps S2, S3, S4 and S5). 
Server 402 thereupon returns its own subnetwork ad- 
dress (SN) on the subnetwork corresponding to the ST 
optional header field received in the request (ISDN in 
this example). This SN is returned to client 401 on the 
Internet through routers 406, 405, 404 and proxy 403 in 
steps SB, S7, 88. S9 and SI 0. The client-side proxy 403 
then sets up a two-way cut-through connection to server 

402 over the ISDN subnetwork 407 through ISDN 
switches 408, 409 and 410. in steps S1 1 and SI 2. Client 
401 then requests information from server 402 over that 
direct connection in step SI 3. Server 402 responds over 
that same two-way direct connection. 

When the client 401 and proxy 403 are not co-res- 
Ident on the same machine but communicate via router 
404, the cut-through may be made between the proxy 

403 and server 402. In this case, which is not separately 
illustrated, but for which FIG. 4 is again referred to. the 
Intermediate System (IS) is proxy 403. Proxy 403 re- 
ceives, via router 404, the HTTP request from client 401. 
Proxy 403 then adds its own subnetwork type as an op- 



tional header, and forwards the modified request to HT- 
TP server 402 via routers 405 and 406. Server 402 re- 
turns its own sub-network address (corresponding to the 
given ST) to proxy 403 in an optional header. Proxy 403 

s then sets up a two-way connection to server 403, and 
the proxy 403 thereafter communicates with client 401 
via router 404. 

The present invention can be applied to multimedia 
conferencing scenarios. With reference to FIG. 5, three 

10 clients, 501-1 - 501-3, are to be conferenced together 
via a multimedia bridge/server 502. For each client 
501 (/ e 1 , 2, 3), client 501 -/ or its associated proxy 
(not shown) sends its subnetwork type and address on 
ISDN subnetwork 510 (and optionally a conference 

IS identifier) to the WWW server 503 via an optional header 
through the appropriate network routers on the Internet 
520 (e.g., 504. 505. 506, 507 and 508) In step SI-/. Send- 
er 503 then sends, via the Internet, the subnetwork ad- 
dress on ISDN subnetwork 510 of each client 501-i to 

20 bridge/server 502 in step 82. Bridge 502 then establish- 
es a direct two-way connection on ISDN subnetwork 
510 to each client 501-/ in step S3-/. Communication 
then proceeds between the clients 501-1 - 501-3, 
through bridge 502, on the ISDN subnetwork 510, 

25 through the ISDN switches 51T 512. 513 and 514. Al- 
though illustrated in FIG. 5 with three clients communi- 
cating with each other, it should be recognized that this 
could be readily expanded to any number of clients, N. 
Alternatively, but not separately illustrated, but for 

30 which FIG. 5 can also be referred to, each client 501-/ 
(/■ E 1 , 2, 3) (or its proxy) can send its subnetwork ad- 
dress to server 503 via an optional header Server 503 
then sends the subnetwork address of bridge 502 (and 
optionally a conference identifier) to client 501-/ (or its 

35 proxy) via a optional header. Each client 501-/ (or its 
proxy) then establishes a two-way connection to bridge 
502. 

The three (or N, more generally) clients may wish 
to conference together without using a multimedia 

40 bridge, but rather through a subnetwork which can pro- 
vide one-way point-to-multipoint capability, such as an 
ATM subnetwork. For this scenario each client / (/ E 1 , 
2, 3) (or its proxy) sends its subnetwork address to a 
server via an optional header. The server then sends a 

45 list of the subnetwork addresses of each client i to all 
sending clients j (J ^ /) via optional headers. For each 
client yt/V /), client y (or Its proxy) establishes a 1-to-3 
multipoint connection to each client /. 

The above-described embodiments are illustrative 

50 of the principles of the present invention. Other embod- 
iments may be devised by those skilled in the art without 
departing from the spirit and scope of the present inven- 
tion. 



Claims 

1. A method of transferring connection management 
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in(orm;iiion comprising: 

transmit ling between a first endpoint host and 
h second cncpoini host at least one optional header 
hole cooiaining infornnation for enabling the direct 
connect on on a subnetwork of the second endpoint 
host Hnd a predetermined host. 



ment information further comprises information for 
specifying a Quality of Service on the direct connec- 
tion on the subnetwork. 

5 13. The method of claim 8 wherein the at least one op- 
tional header field is an HTTP header. 



2. The method of claim 1 wherein the information for 
cnaDiing the direct connection on the subnetwork 
of the second endpoint host and a predetermined 
host comprises the address on the subnetwork of 
Inc predetermined host. 

3. The method of claim 2 wherein the predetermined 
hos: IS the first host. 

4. The moirxxJ ol claim 2 wherein the predetermined 
host IS a proxy for the first host. 

5. The moliKxi ol claim 2 wherein the information for 
enablifiy Oic diioct connection on the subnetwork 
of the first and second hosts further comprises in- 
fornrviton lor spoctlying a Quality of Service (QoS) 
on the direct connection. 

6. The moliiod of claim 1 wherein the information for 
enabling the direct connection on the subnetwork 
of the first arxj second hosts comprises the type of 
subnetwork 

7. The method of claim 1 wherein the optional header 
field is an HTTP header. 

8. A method of transferring information from a server 
connected on a data network comprising: 

recorving at the server on the data network at 
least one optional header field containing con- 
trol management information, the control man- 
agement information comprising an address on 
a subnetwork of a predetermined host; and 
using the address on the subnetwork received 
in the at least one optional header field, estab- 
lishing a direct connection on the subnetwork 
between the server and the predetermined 
host 

9. The method ol clciim 8 wherein the predetermined 
host is a client 

10. The method of claim 8 wherein the predetermined 

host is a proxy for a client. 

11. The method of claim 8 wherein the control manage- 
ment information further comprises the type of net- 
work the subnetwork is. 

1 2. The method of claim 8 wherein the control manage- 



14. A method of transferring information from a server 
connected on a data network comprising: 

10 

receiving on the data network from the server 
at a predetermined host at least one optional 
header field containing control management in- 
formation, the control management information 
IS comprising an address on a subnetwork of the 

server; and 

using the address on the subnetwork of the 
server received in the at least one optional 
header field, establishing a direct connection 
20 on the subnetwork from the predetermined host 

to the server. 

15. The method of claim 1 4 further comprising the step 
of receiving on the data network from the predeter- 

25 mined host at the server at least one optional head- 
er field containing control management information 
indicating the type of the subnetwork. 

16. The method of claim 14 wherein the predetermined 
30 host is a client. 

17. The method of claim 14 wherein the predetermined 
host is a proxy for a client. 

35 18. A method of bridging together a plurality of hosts on 
a data network comprising: 

receiving at a bridge on the data network from 
each of the plurality of hosts at least one op- 
40 tional header field containing control manage- 

ment information, the control management in- 
formation from each host comprising an ad- 
dress on a subnetwork of the host; and 
establishing a direct connection on the subnet- 
45 work between the bridge and each of the plu- 

rality of hosts using the address on the subnet- 
work received from each of host. 

19. A method of bridging together at a bridge a plurality 
50 of hosts on a data network comprising: 

sending on the data network to each of the plu- 
rality of hosts in at least one optional header 
field containing control management 
55 information , the control management informa- 

tion comprising an address on the subnetwork 
of the bridge; and 

establishing a direct connection on the subnet- 
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work between each of the plurality of hosts and 
the bridge using the address on the subnetwork 
of the bridge. 
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FIG. 1 
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FIG. 3 
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